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AGREEMENT MANAGEMENT SYSTEM 

Background of the Invention 
Field of the Invention 

5 The present invention relates to an agreement 

management system assisting in agreement operations. 

Description of the Related Art 

For contracts or agreements such as a patent 

10 agreement, a know-how agreement, a joint development 
agreement, etc., parties (companies, or an individual 
and a company) exchange written agreements. At the time 
of the agreement, the scope of a license, consideration 
conditions, etc. are mutually arranged. Agreement 

15 management is usually made by various divisions such 
as a division responsible for an agreement (division 
that negotiates the agreement) , a division managing a 
right, an accounting division handing a balance, etc. 
Furthermore, management of an agreement is made in various 

20 forms. For example, a division responsible for an 
agreement may vary by an agreement type, and a division 
managing an agreement (agreement management division) 
differs from a division storing a written agreement (an 
agreement storing division) . 

25 If the number of agreements is small, and if one 
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division collectively manages agreements, accesses to 
the written agreements, etc. can be made with relative 
ease on demand. However, if the number of agreements 
is considerably large, and if divisions that handle the 
5 agreements are mutually independent, the following 
problems occur. 

• A division in charge of an agreement is burdened 
with the responsibility of holding documents relevant 
to the agreement. Accordingly, documents relevant to 

10 agreements spread over respective divisions . Therefore, 
it takes time to find out what agreements exist as a 
whole. Additionally, for example, when negotiation is 
newly made with a certain company, an examination must 
be made across divisions to grasp the past agreement 

15 relationships, which forces troublesome operations. 

As described above, divisions to which managed 
agreements are relevant are diverse. Examples of such 
divisions include a management source of a right, which 
is the base of an agreement, a division in charge of 

20 negotiation, a division managing a balance, a division 
issuing a bill (accounting . division, etc.), etc. 
Predetermined procedures (a request for a managerial 
decision, etc.) are essential to conclude an agreement 
depending on a company . Therefore, documents which occur 

25 in accompaniment with an agreement must be managed. 
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Additionally, since agreement contents, etc. are 
stored on a paper basis, an access must be made to each 
agreement file in order to learn about terms and 
conditions (licensing conditions or consideration 
5 conditions, restriction articles, etc.) of each 
agreement. Especially, difficulties exist in attempts 
to grasp the past income or payments based on an agreement 
relevant to an intellectual property right of a patent, 
etc. (although rights to be treated with agreements of 

10 a patent, a utility model, a design, a trademark, or 
the like are diverse, rights to be permitted, transferred, 
etc. as intellectual property rights are generically 
called "patent" unless otherwise noted. Additionally, 
although "a right is permitted" or "a right is 

15 transferred" depending on an agreement, "permit" is 
generically used including the meaning of "transfer" 
in some cases where a distinction is not required, unless 
otherwise noted) . 

Referred to as "patent accounting", etc., 

20 attention has been paid to a relationship between a 
balance relevant to intellectual property rights and 
settlement of balance (balance sheet, etc.) of an entire 
company in recent years, so that a balance relevant to 
intellectual property rights must be reflected on the 

25 profitability of an entire company. However, the above 
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described way of managing each agreement causes an 
inconvenience in actually including the balance relevant 
to intellectual property rights in the settlement of 
balance of the entire company. 
5 Additionally, the income or payment of a license 

fee under an agreement is sometimes distributed or shared 
to a company other than agreement parties . Also management 
of an income earned by such an agreement type is not 
easy. For example, if an agreement is made as a 

10 representative with another company for a joint right, 
part of an income earned by that agreement is distributed 
to a joint partner, or also a payment is similarly shared 
in some cases. 

In the meantime, a similar problem occurs within 

15 a company. If a license income, etc. is earned for a 
right managed across divisions within the company, the 
incomemust be distributed to the divisions . Additionally, 
a payment (expenditure) must be shared by divisions. 
Such a distribution or sharing among divisions within 

20 a company cannot be easily managed if documents relevant 
to an agreement spread and are held by individual 
divisions . 

Furthermore, there may be cases where contents of 
an agreement are changed by exchanging a memorandum of 
25 understanding after the agreement is concluded. Also 
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a memorandum of understanding is an agreement which 
accompanies the original agreement if the memorandum 
of understanding is exchanged (corresponding to an 
addition of an agreement condition) due to an addition 
5 of a licensed product or a license, etc. after the 
agreement is concluded. Therefore, the memorandum of 
understanding must be managed in association with the 
original agreement. However, this handling is also 
troublesome . 

10 The phenomenon that the current agreement state 

cannot be easily grasped causes an inconvenience in 
determining a policy of license activities, and in 
creating basic materials, which can possibly prevent 
an effective policy decision. 

15 Accordingly, it is desirable that written 

agreements, etc. are collectively managed within a 
company. However, managing all of written agreements, 
etc. also encounters technical difficulties. This is 
because divisions involved in the written agreements 

20 are diverse, and the number of agreements becomes large. 

In the meantime, for a written agreement, a heavy 
restriction such as confidentiality, etc. is imposed 
in terms of management, and security is important. 
Accordingly, since collectively managing written 

25 documents, etc. is risky, the collective management was 
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not made also in terms of security on which importance 
is placed. 

Conventionally, however, attempts were made to 
efficiently manage agreements. 
5 Patent Document 1 discloses a technique for 

managing an agreement term, for calculating the 
termination date of the agreement term, and for presenting 
to a user an agreement the termination date of which 
is close. Patent Document 2 discloses a technique for 

10 managing legal operations, with which agreement 
negotiation request information and agreement request 
details information are extracted from a database, the 
extracted information is combined with information from 
a business division to create and record concluded 

15 agreement information, an agreement term is managed, 
and a notification is made to a responsible person when 
the agreement expiry date approaches. Patent Document 
3 discloses a configuration where confidentiality is 
maintained in data management. Also Patent Document 4 

20 discloses a technique related to confidentiality in a 
database system, which determines whether or not topermit 
an access to data depending on a division in an 
organization, a job title, etc. Also Patent Document 
5 discloses a technique for restricting an access to 

25 document data, and for permitting an access to a document 
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according to a use right. 

[Patent Document 1] 
Japanese Patent Application Publication No . 2001-117998 
[Patent Document 2] 
5 Japanese Patent Application Publication No . 2001-216407 
[Patent Document 3] 
Japanese Patent Application Publication No. HEI9-6681 

[Patent Document 4] 
Japanese Patent Application Publication No. 2000-20377' 
10 [Patent Document 5] 

Japanese Patent Application Publication No . 2001-142874 
Conventionally, a proposal to electronify a 
written agreement format, etc., and to automatically 
create a written agreement form is made. Especially, 
15 this is applied to an insurance agreement, a credit card 
agreement by mail order, etc. 

Besides, conventionally, even if an agreement 
management system exists, thenumber of types of agreement 
is large, and management of an income/expenditure 
20 accompanying an agreement is complicated. Therefore, 
an effective and functional use of agreement data has 
not yet been considered yet although attempts to 
electronicallymanage an agreement have beenmade instead 
of writing it down as an agreement list. 

25 



Summary of the Invention 

An object of the present invention is to provide 
a system assisting in agreement management with which 
data such as a patent agreement, etc. can be effectively 
5 and functionally used. 

The system according to the present invention 
comprises: an agreement database to which at least basic 
information, an agreement target, and agreement 
conditions among information about an agreement are 

10 registered; a balance database to which a running royalty 
and balance information, which are relevant to the 
agreement, are registered; and an operating unit 
performing an operation such as registration, 
modification, reference, search, inquiry, display or 

15 printing for the data relevant to the agreement registered 
to the balance database. 

According to the present invention, data obtained 
relevantly to an agreement are collectively managed, 
and can be used effectively and functionally on demand, 

20 leading to an increase in the efficiency of operations 
of a division that handles a number of agreements, such 
as patent operations, etc. Besides, the larger an 
organization that introduces the system according to 
the present invention, the easier the obtainment of a 

25 balance, etc. of agreements within an entire company. 
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This simplifies information exchange of agreement 
relationships within the entire company. 

Brief Description of the Drawings 

5 Fig. 1 exemplifies the configuration of a system 

to which a preferred embodiment according to the present 
invention is applied; 

Fig. 2 shows the configuration of functions of the 
system according to the preferred embodiment of the 
10 present invention; 

Fig. 3 shows the relationship among data in a 
database; 

Fig. 4 exemplifies the data structure of a master 
database; 

15 Fig. 5 is a schematic (conceptual schematic No. 

1) exemplifying a data structure of a database for 
managing agreements, which is extended in a memory, in 
the system according to the preferred embodiment of the 
present invention; 

20 Fig. 6 is a schematic (conceptual schematic No. 

2) exemplifying a data structure of the database for 
managing agreements, which is extended in the memory, 
in the system according to the preferred embodiment of 
the present invention; 

25 Fig. 7 shows a transition (No. 1) of a display made 
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on a display unit of the system according to the preferred 
embodiment of the present invention; 

Fig. 8 shows a transition (No. 2) of the display 
made on the display unit of the system according to the 
5 preferred embodiment of the present invention; 

Fig. 9 shows a transition (No. 3) of the display 
made on the display unit of the system according to the 
preferred embodiment of the present invention; 

Fig. 10 shows a transition (No. 4) of the display 
10 made on the display unit of the system according to the 
preferred embodiment of the present invention; 

Fig. 11 shows the classification of agreement party 
relationships ; 

Fig. 12 exemplifies the configuration of a 
15 registration/modification screen; 

Fig. 13 exemplifies an agreement basic information 
(bibliographical items) registration screen; 

Fig. 14 exemplifies an input screen of other 
agreement conditions ; 
20 Fig. 15 shows a configuration example of each screen 

(for search) (No. 1) ; 

Fig. 16 shows a configuration example of eachscreen 
(for search) (No. 2); 

Fig. 17 shows a configuration example of each screen 
25 (for search) (No. 3); 



11 



Fig. 18 shows a configuration example of each screen 
(for search) (No, 4); 

Fig, 19 shows a configuration example of each screen 
(for search) (No- 5) ; 
5 Fig. 20 shows a configuration example of each screen 

(for search) (No. 6) ; 

Fig. 21 exemplifies an agreement list display 
resultant from a search; 

Fig. 22 exemplifies an agreement original (for 
10 example, a summary of the agreement) display; 

Fig. 23 explains the downloading of agreement data 
in a CSV format and its display (No. 1); 

Fig. 24 explains the downloading of agreement data 
in a CSV format and its display (No. 2); 
15 Fig. 25 exemplifies the configuration of a balance 

data screen (registration/modification) ; 

Fig. 26 exemplifies an input screen of a deposit; 
Fig. 27 exemplifies an input screen of installments 
such as a deposit, etc.; 
20 Fig. 28 exemplifies a royalty balance input screen; 

Fig. 29 exemplifies an other balance input screen; 
Fig . 30 exemplifies an implementation report (such 
as royalty report) state inquiry screen; 

Fig. 31 exemplifies an implementation report (such 
25 as royalty report) state search result screen; 
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Fig. 32 explains access rights (No. 1) ; 

Fig. 33 explains access rights (No. 2) ; 

Fig. 34 explains access rights (No. 3) ; 

Fig. 35 explains access rights (No. 4); 
5 Fig. 36 explains an access right (No. 5) ; 

Fig. 37 explains an access right (No. 6) ; 

Fig. 38 exemplifies a screen relevant to 
statistical data (No. 1); 

Fig. 39 exemplifies a screen relevant to 
10 statistical data (No. 2) ; 

Figs. 40A through 40C exemplify a screen relevant 
to statistical data (No. 3) ; 

Fig. 41 exemplifies a screen relevant to 
statistical data (No. 4); 
15 Fig. 42 exemplifies a screen relevant to 

statistical data (No. 5) ; 

Fig. 43 is a flowchart showing a 
registration/modi f icat ion/ re edit ion process starting 
from login; 

20 Fig. 44 is a flowchart showing a subnuraber process; 

Fig. 45 is a flowchart showing a process for 
registering basic information; 

Fig. 46 is a flowchart showing a process for 
registering data of an agreement target; 
25 Fig.47isa flowchart showing a process for setting 
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, other agreement conditions; 

Fig . 48 is a flowchart showing a process for setting 
a consideration condition; 

Fig. 49 is a flowchart showing a process for 
5 inputting relevant information; 

Fig. 50 is a flowchart showing a process for 
registering an electronically stored document; 

Fig. 51 is a flowchart showing a process for 
registering balance data; 
10 Fig. 52 is a flowchart showing a process for 

registering other balance information; 

Fig. 53 is a flowchart showing a search/inquiry 
process ; 

Fig. 54 is a flowchart showing an alarm process: 
15 Fig. 55 is a flowchart showing an alarm process 

for the receipt of an implementation report (such as 
royalty report) ; 

Fig. 56 is a flowchart showing an alarm process 
for the submission of an implementation report (such 
20 as royalty report) ; 

Fig. 57 is a flowchart showing an alarm process 
for installments; and 

Fig. 58 is a flowchart showing a statistical data 
process . 

25 
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Description of the Preferred Embodiments 

To collectively manage agreement data, adequate 
security is required. Agreement data itself is naturally 
stored by being encrypted. Additionally, for agreement 
5 data, whichcannot be disclosedamong divisions, anaccess 
to the data, which is made across divisions, must be 
prohibited. Furthermore, to enable agreement data to 
be used effectively and functionally, balance data of 
a particular agreement must be easily obtained, and a 
10 balance accompanying agreements as an entire company 
must be easily grasped. 

To overcome the above described issues, the 
following measures are required. 

Enabling necessary agreement data to be easily 
,15 searched. 

Enabling the scope of disclosure, an agreement to 
be disclosed, etc. to be selected with an access 
restriction in the search. 

Facilitating the management of materials 
20 (documents) accompanying an agreement along with its 
written agreement, because base materials prior to an 
agreement, agreement negotiation materials, materials 
after the agreement is concluded, etc. amass a huge 
volume . 

25 - Also enabling the management of a change or an 
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addition made to agreement contents with a memorandum 
of understanding. 

Enabling an agreement with the same company to be 
easily searched even if a change is made to a company 
5 name or the like. 

- Enabling measures to be easily taken even if a 
division name or a division is abolished or merged, or 
transferred to a new division, etc. 

Enabling an agreement expiry date, especially, the 
10 renewal or the automatic termination of an agreement 
to be coped with. 

Enabling installments in accordance with an 
agreement to be coped with. 

Enabling a deadline to be managed, because an 
15 implementation report (such as royalty report) , etc. 
in accordance with an agreement is mandatory. 

- Enabling control tobe performed in order to prevent 
data from overflowing due to a large number of items 
when downloading the data with an existing application, 

20 because necessary items (the number of items) in an 
agreement becomes very large, and an output of the data 
becomes a problem in the case where the agreement is 
put into a database. 

To implement the above described measures, the 

25 following functions are provided according to a preferred 
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embodiment of the present invention. 

Management of an agreement is based on a target 
right and a consideration. 

Clarifying a target right. 
5 — Enabling data such as the scope of a right, etc. 
to be registered for each right. 

Managing both of an income and expenditure as 
considerations . 

Managing an income and expenditure (payment) 
10 if considerations are mutually exchangedbetween parties 
in one agreement. 

- Managing incomes from a plurality of 

counterparts among a plurality of parties. 

Managing the case where a payment is incurred 
15 to a plurality of counterparts among a plurality of 
parties. 

— Managing an agreement by regarding each payment 
or each income of a consideration as an individual 
agreement, for one agreement which incurs a plurality 
20 of incomes/payments (one agreement is virtually regarded 
as a plurality of agreements, and registered) . 

There are two types of management methods as this 
technique: a method independently taking a management 
number, and a method generating and adding a subnumber. 
25 - Managing the distribution/sharing of a 
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consideration. 

— Managing the distribution/sharing made by 
relevant divisions within a company. 

— Managing the distribution/sharing among parties 
5 relevant to an agreement other than parties concluding 

the agreement. 

Enabling an access right to be given for each. data 

block. 

Grouping access rights for each division. 
10 - Enabling a division responsible for an 

agreement to view agreement data, even if an access made 
from a person outside the division is prohibited for 
the agreement data of a different division. 

- Performing control for contents of each 
15 agreement with an access right, although the existence 

of an agreement as an agreement list can be viewed by 
everybody. Also performing control such that part of 
an agreement list, such as a summary (title, etc.), etc., 
which is relevant to agreement contents, is not to be 
20 permitted to be viewed. 

- Enabling an agreement party relationship to 
be clearly grasped (displayed on a screen) . 

Enabling many agreement items to be briefly 
viewed (an agreement original display on a screen) . 
25 - Enabling a right relationship among , a 



plurality of parties to be grasped (supported with 
* subnumbers) . 

Classifying data inputs made by a plurality 
of parties into a common item and an individual item 
5 in order to reduce the operations of condition inputs, 
and executing a copy process for the common item 
(especially, in a subnumber process) . 

Also enabling a common item for which the 
copy process is executed to be modified/changed. 

10 - Enabling data to be output by adding an item 

regardless of the number of items to put the data into 
a block in a data output. 

Enabling the state of a target right in an 
agreement to be updated. 

15 Fig. 1 exemplifies the configuration of a system 

to which the preferred embodiment according to the present 
invention is applied. A database 13 is a storage medium 
storing agreement information. A server 12 stores 
agreement information in the database, and manages the 

20 information. PC terminals 14-1 to 14-n, and 14-n+l to 
14-m are a plurality of user side terminals (user 
terminals), such as personal computers, for registering, 
searching, and referencing agreement information. In 
the preferred embodiment, the user terminals 14-1 to 

25 14-n are connected to the server 12 via a connecting 
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device 11, so that they can access the database. The 
user terminals 14-n+l to 14-m, and the server 12 are 
connected via a connecting device 11 and a network 10. 

According to the present invention, use forms such 
5 as a form where the server 12 and the user terminals 
14-1 to 14-m are located in the same site (in the same 
building, etc.), or a form where the server 12 and the 
user terminals 14-1 to 14-m are connected via a network 
(the Internet/intranet, etc., a company-wide LAN, a 

10 network via a communications line, etc.) may be 
implemented. A connection form of the server 12 and the 
user terminals 14-1 to 14-m is not particularly limited. 

Usage of the terms "register" and "modify" is as 
follows. Since the term "modify" means that registered 

15 data is changed (modified) and the data is again 
registered, "modify" also includes the meaning of 
re-registration". Accordingly, "register" is 
generically used as a technical meaning, and sometimes 
includes the meaning of "modify" unless a distinction 

20 is required. 

Fig. 2 shows the configuration of functions of the 
system according to the preferred embodiment of the 
present invention . 

An agreement contents database 20 storing 

25 information such as agreement parties, an agreement form, 
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agreement conditions, etc, as agreement information, 
abalance database 21 storing data (balance data) relevant 
to a balance such as a deposit, a royalty, etc., which 
is incurred after the agreement is concluded, and an 
5 agreement relevant document database 22 storing 
documents such as a written agreement, an implementation 
report (such as royalty report) occurring in 
accompaniment with the agreement, a bill or the like, 
negotiation materials for reaching an agreement, 

10 negotiation minutes, etc. are provided. These databases 
may be configured physically as one database, or as 
separate databases . 

An agreement contents registration/modification 
function 23 is a function (man-machine interface) for 

15 making a user register or modify contents of an agreement, 
and is used to register contents of an agreement to the 
agreement contents database 20, or to modify contents 
of a registered agreement. A balance data 
registration/modification function 24 is a function 

20 (man-machine interface) for making a user register or 
modify balance data, and is used to register balance 
data to the balance database 21, or to modify balance 
data. 

An agreement relevant document 

25 registration/modification function 25 (for electronic 
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data, text, image data, etc.) is a function (man-machine 
interface) with which a user registers the above described 
documents relevant to an agreement to be electronically 
stored, or modifies a registered document (including 
5 adeletion, etc. of a document which becomes unnecessary) , 
and is used to register document data to the agreement 
relevant document database 22, or to modify registered 
document data. 

An agreement information search/inquiry function 

10 2 6 is a function for searching or inquiring about contents 
of an agreement stored in the agreement contents database 
20. An agreement information downloading function 36 
(for example, downloading of data in a CSV format) is 
a function for downloading electronically stored 

15 agreement data, which is searched or inquired by the 
agreement information search/inquiry function 2 6 and 
stored in the agreement contents database 20 and the 
balance database 21, as it is. 

An agreement relevant document search/inquiry 

20 function 27 is a function for searching/inquiring about 
an agreement relevant document stored in the agreement 
relevant document database 22 • An agreement relevant 
document downloading function 37 is a function for 
downloading data of an agreement relevant document 

25 searched or inquired by the agreement relevant document 
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search/inquiry function 27. 

An implementation report (such as royalty report) 
state search/inquiry function 28 is a function for 
searching the data stored in the agreement contents 
5 database 20, the balance database 21, and the agreement 
relevant document database 22 for the current 
implementation state of an agreement, the payment state 
of a running royalty, etc . An implementation report (such 
as royalty report) state list output function 38 is a 

10 function for displaying on the display unit or printing 
a list of implementation states searched or inquired 
by the implementation report (such as royalty report) 
state search/inquiry function 28. Note that some 
agreements can possibly have no obligation to report 

15 their implementation state, and others can possibly make 
an arrangement to abort or resume an implementation report 
( such as royalty report) depending on an implementation 
state . Accordingly, for the above described registration 
of agreement contents data, when there is no 

20 implementation report (such as royalty report ) although 
an arrangement of a running royalty, etc. is made as 
• a consideration condition, or when an implementation 
report (such as royalty report) is aborted to be made, 
resumed, etc., during the implementation of the agreement , 

25 data such as unsubmission, abortion, resume, etc. of 
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an implementation report (such as royalty report) is 
registered depending on the implementation state of 
agreement contents, whereby agreements whose 
implementation report (such as royalty report) s are 
5 not made can be also excluded from an implementation 
state list to be output. 

A bill creation function 29 is a function for 
creating a bill according to an implementation state 
when a company on this side requests a payment to an 

10 agreement counterpart. The created bill is printed with 
a bill output function 39. 

A statistical data specification function 30 is 
a function for specifying, for the system, which type 
of statistical data is to be obtained when acquiring 

15 statistical data of a balance in accordance with an 
agreement, such as balance data of each agreement in 
an entire company, balance data of each agreement in 
each division, etc. A statistical data output function 
40 is a function for displaying or printing statistical 

20 data based on the target data to be specified by the 
statistical data specification function 30. 

An access right setting function 31 is a function 
for setting an access right to the data stored in the 
agreement contents database 20, the balance database 

25 21, and the agreement relevant document database 22. 
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An agreement list output function 34 is a function 
for displaying and printing, as a list, predetermined 
items among agreement contents stored in the agreement 
contents database 20 . An agreement original ( for example, 
5 a summary of the agreement) output function 35 is a 
function for displaying and printing details of contents 
of each agreement specified by search or inquiry among 
agreement contents data andbalance data, which are stored 
in the agreement contents database 2 0 and the balance 

10 database 21. 

An alarm type notification function 41 is a function 
for notifying a responsible person that an expiry date 
or a deadline is close in the case where a term of a 
particular agreement is about to expire, or its 

15 implementation report (such as royalty report) deadline 
is about to come. 

A master database 33 stores data such as division 
information (ladder master) used at the time of login 
to the system, registration of agreement data, etc., 

20 access right giving or checking (personnel master) , 
identification data of a country, party data (company 
code, company name, etc.), and the like at the time of 
data registration . 

Also the master database 33 is described as a 

25 database separate f romthe databases such as the agreement 
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contents database 20, and the like. However, these 
databases may be physically one or a plurality of 
databases, and their configurations are not particularly 
limited. 

5 Fig. 3 shows the relationship among data in a 

database. 

Conventionally, building a unified database was 
considered to be difficult. The reason that management 
of agreement information is difficult and cannot be 

10 configured as a system is as follows: documents of an 
agreement and data of agreement conditions, etc. may 
vary depending on the type of an agreement, and 
construction of a unified database was considered to 
be difficult. The present invention solves this problem 

15 by devising the structure of data as a configuration 
of an agreement information database. 

Attention is focused on agreement information, 
which is composed of agreement contents data indicating 
contents of an agreement, balance data accompanying the 

20 agreement, and documents relevant to the agreement, and 
the relationship among these items of data is built in 
a database as shown in Fig. 3. 

Documents relevant to an agreement among agreement 
information 30a include a written agreement 37a and a 

25 memorandum of understanding 38a, which are- composed of 
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document data (electronic data) such as text data, Word 
(trademark) data, Excel (trademark) data, etc., and a 
written agreement 371, a memorandum of understanding 
381, details of an implementation report (such as royalty 
5 report) 39a, and other relevant documents 3A, which are 
composed of image data (electronic data) . These data 
items are merely examples, and do not limit the format 
or the type of a document. An agreement negotiation 
progress table, minutes, etc. in a text format may be 

10 stored depending on need. 

Additionally, agreement contents data of the 
agreement information include an agreement parties 
relationship 31a which indicates parties concluding an 
agreement, the scope of a license 311 as an agreement 

15 condition, the scope of a licensed patent/product 312; 
other agreement conditions 32a arranged by the agreement, 
consideration conditions 33a such as a deposit, a running 
royalty, etc., agreement relevant information 36a such 
as an attorney's fee accompanying the agreement, etc. 

20 Balance data of the agreement information include 

a royalty balance 34a as management data of the 
presence/absence of a payment/income of a deposit or 
a running royalty, and other royalty balance 35a 
indicating the distribution, sharing, etc. to a joint 

25 applicant other than agreement parties, or a compensation 
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payment, etc., in addition to a normal royalty. The 
royalty balance 34a includes, as a classification of 
the royalty balance, an agreement deposit 341 (sometimes 
includes a past royalty or an advance committed to the 
5 future royalty, a transfer expense, etc. incurred when 
a right is transferred, in addition to a deposit as an 
agreement commission, etc.), a running royalty 
stipulated as a specific amount of money, and an arrears 
interest prescribed by a consideration condition. The 

10 other royalty balance 35a includes aparties relationship 
351 stipulating a balance relationship other than 
agreement parties, an agreement deposit 3511, a running 
royalty 3512, etc. 

Fig. 4 exemplifies the data structure of the master 

15 database. 

Employee data shown in Fig. 4A is used to verify 
an employee and his or her division when an access right 
is given to the employee (user) who uses the system 
according to the preferred embodiment of the present 

2 0 invention, and to verify an employee when he or she inputs 
each agreement data. 

As agreement party data shown in Fig. 4B, a company 
code and a company name are registered. A company name 
can be input as the registration of agreement data. 

25 As agreement party data shown in Fig. 4B, a company 
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code and a company name are registered. As a registration 
of agreement data, not only a company name can be directly 
input, but also a company code can be input* 

For a company name, there are various cases such 
5 as a case where a common or abbreviated name is used, 
a case where, for example, "stock company" precedes or 
succeeds a company name, a case where "stock company" 
is abbreviated to "Co. Ltd." or spelled out, and the 
like. Accordingly, if agreement data is input according 

10 to a user' s liking, who registers agreement data, company 
name data is not uniform in notation, which is 
inconvenient to a data search. To avoid this problem, 
a method inputting a company name may be regularized. 
In this preferred embodiment according to the present 

15 invention, all of inputs are made with a company code, 
and master data that makes a correspondence between a 
company code and a company name is comprised. This 
registration method using a company code can unify data 
irrespective of users, and can easily cope with a case 

2 0 where a company name is changed. Also an input error 
of a user who registers data can be prevented. 

A target company code used when a user registers 
or searches agreement data is obtained by indexing this 
database . 

25 In division data shown in Fig . 4C, a division code, 
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a subordinate department code, a division (name) , and 
a department name are registered in correspondence. An 
advantage that a division code and a department code 
are used instead of a division name and a department 
5 name when agreement data is registered is similar to 
that in the case of party data. If a department code 
does not exist, only a division code can be input. Or, 
a change can be appropriately made . For example, a section 
code is provided subordinately to a department code. 

10 As currency unit data shown in Fig. 4D, currency unit 
codes and unit names are registered. This data is 
referenced to decide the unit of a money amount when 
a consideration condition or data of a royalty balance 
is input. With this data, for example, any of a case 

15 where a royalty is decided to be paid in yen when an 
enterprise in a foreign country and an enterprise in 
Japan conclude an agreement, and a case where a royalty 
is decided to be paid in a currency unit of a foreign 
country can be coped with. 

20 Country codes shown in Fig. 4E are referenced when 

a country name of an agreement party is specified and 
registered. 

When an agreement list or an agreement original 
(for example, a summary of the agreement) is output, 
25 an abbreviation (code) of a country is displayed along 
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with a party name (company name) by the system. 

Figs. 5 and 6 are schematics (conceptual 
schematics) exemplifying a data structure of the database 
for managing agreements, which is extended in the memory, 
5 in the system according to the preferred embodiment of 
the present invention. 

As shown in Fig. 5, information of one agreement 
is stored under one management number. As basic 
information, an agreement type, agreement parties, an 

10 agreement conclusion date, an agreement term, an 
agreement expiry date, and an agreement termination date 
(actual termination date) are registered as 
bibliographical items in addition to a management number . 
Also divisions involved in the agreement managed with 

15 the management number are registered. Registered 
divisions are an agreement management division, an 
agreement conclusion division, a balance relevant 
division, and other relevant divisions. A division may 
be added depending on need. Agreement target items 

20 stipulate a specific right permitting/permitted by an 
agreement, and are configured by agreement parties (data 
indicating from whom to whom) , a license class (normal 
license, exclusive license, etc.), patent (including 
number specification, package licensing, etc.), 

25 know-how, product, treatment of a subsidiary, etc. The 
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target agreement items are organized by an agreement 
party, and provided for each agreement party. Kl, K2, . . . 
Kn of Fig, 5 indicate that right information, etc. as 
agreement targets among n different agreement parties 
5 are/can be independently registered in an agreement 
stipulated based on basic information. Additionally, 
the right information for each of the agreement parties 
Kl, K2, . . .Kn can be individually registered as license 
classes Kll, K2, ,Kln, K21, K22,...K2n. Furthermore, 

10 since a plurality of patents, know-how, and products 
can possibly exist for each of the license classes Kl, . . . , 
these are allowed to be set. The example of Fig. 5 shows 
that a plurality of patents Kill to Klin are/can be 
registered for a patent. Also a plurality of patents 

15 K121 to K12n in a license class K12..., a plurality of 
patents K211 to K21n in a license class K21..., and a 
plurality of patents K221 to K22n in a license class 
K22... are similar, and the respective license classes 
identify all of patents permitted to be used by one license 

20 agreement. This is similar for know-how and products. 

With such a configuration, with one agreement, 
rights of both parties when a plurality of agreement 
parties (not limited to two companies) mutually grant 
25 licenses, or all of rights the license classes of which 
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are different can be registered. 

For an agreement identified with the basic 
information, other agreement conditions are provided, 
and a portion which records a treatment after agreement 
5 termination is provided. 

Additionally, also consideration conditions in an 
agreement are recorded as important items of agreement 
data. As the consideration conditions, a distinction 
between income and expenditure, a deposit, etc., a running 

10 royalty, an arrears interest, distribution/sharing 
division information, and counterpart information are 
registered. If consideration conditions (including 
mutual payments) are set among a plurality of parties 
in one agreement, exactly the same consideration 

15 conditions are rarely stipulated. Accordingly, for 
example, 6 types of consideration conditions can be 
possibly stipulated in an agreement concluded among 3 
companies as the consideration conditions registration 
among the parties. This is also one of conventional 

20 reasons that make it difficult to put agreement data 
into a database, and to manage the data. The present 
invention focuses attention on the flow of a balance 
(stipulated by a consideration condition) among 
agreement parties, and implements a configuration with 

25 an idea that only one consideration condition is allowed 
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to be registered with one agreement management number. 
For example, if an agreement has a form where 
consideration payments are mutually incurred between 
two companies, this agreement is put into a database 
5 by being recognized as two virtual agreements such as 
(1) an agreement of a consideration payment, and (2) 
an agreement of a consideration income. How to handle 
these virtual agreements will be described later. 
Accordingly, the consideration conditions shown in Fig. 

10 5 mean consideration conditions presented from a company 
A to a company B if the agreement parties in the upper 
portion of this figure indicate the license granted from 
the company A to the company B. In this case, the royalty 
balance of the consideration payment to be described 

15 next is payment data from the company B to the company 
A. Here, if a consideration condition from the company 
B to the company A exists, there are two methods in the 
present invention: a method virtually regarding the 
consideration condition as an independent agreement and 

2 0 assigning another management number, and a method adding 
a subnumber of a management number and registering data 
as a virtual agreement for each subnumber. This will 
be described later. 

As relevant information of an agreement at the 

25 bottomof Fig. 5, an agent, etc. are recorded . Aplurality 
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of agents, etc. can be recorded. If an agreement is 
concluded with a plurality of agents, information of 
these agents Dl to Dn are recorded as the relevant 
information . As the agent information, not only a lawyer, 
5 a patent attorney, etc, who is involved in the agreement, 
but also expense information (a consultation fee, lawsuit 
cost, etc.) can be registered. The expense information 
can be reflected on statistical balance data of an 
agreement. For example, a process for subtracting a 
10 lawsuit cost from the income earned by the agreement 
can be executed. Accordingly, as statistical data of 
a royalty balance, more accurate data can be also 
obtained. 

Fig. 6 shows the structure of balance data in an 
15 agreement identified with basic information. As balance 
data of a royalty, etc., a deposit, etc., a running royalty, 
an arrears interest, bill data (for issuing a bill), 
etc. are provided. Installments are respectively 
applicable to these items. The deposit, etc. can be a 
20 deposit payment after an agreement, such as a deposit 
at the time of product shipment, etc. in addition to 
a deposit payment when an agreement is concluded. Also 
the royalty payment is incurred a plurality of times, 
such as a payment for every half year or for every quarter . 
25 The arrears interest and bill data are similar. 
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Accordingly, deposits II to Ij indicate a payment of 
a deposit, etc. made by j times including a case of 
installments. Similarly, the royalty is paid by k times 
as indicated by Jl to Jk, and the arrears interest is 
5 paid by 1 times as indicated by CI to CI. For the bill 
data, its issuance made by n times is recordedas indicated 
by SI to Sn. In these data, data required for managing 
the agreement, such as a payment due date, an 
implementation report (such as royalty report) receipt 

10 date, etc. in addition to a payment amount can be recorded, 
although these are not shown (the term "payment" is 
defined below. If a payment from a company A to a company 
X, and a payment from the company. X to the company A 
are incurred, two events such as a payment and an income 

15 exist when viewed from the company A. Hereinafter, the 
term "payment" also includes the meaning of "income" 
if the direction does not need to be defined) . 

Additionally, as balance data in an agreement 
identified with basic information, other balance data 

20 is recorded. The other balance data is managed by being 
separated into groups HI to Hn, which are identified 
with a distinction between distribution and sharing, 
payer information, and payee information. In each of 
the groups, a deposit, etc., and a running royalty are 

25 recorded also in consideration of installations. For 



36 



the deposit, etc., distribution or sharing made by j 
times Hill to Hllj, and payment distribution or sharing 
made by 2j times HI21 to HI2j are indicated. Also for 
the royalty, distribution or sharing made by lk times 
5 HJ11 to HJlk, and distribution or sharing made by 2k 
times HJ21 to HJ2k are indicated. 

The data structures shown in Figs. 5 and 6 are 
represented as relational databases. However, they may 
be in a transaction form or other forms. 
10 Figs. 7 to 10 are schematics showing transitions 

of a display made on the display unit of the system 
according to the preferred embodiment of the present 
invention . 

The display starts from an initial screen #1 of 
15 Fig. 7. When a user makes registration, the display 
proceeds to a user registration request screen #2. The 
user who desires to register himself inputs necessary 
information on the user registration request screen #2 
to make a request. The system verifies if this request 
20 is redundant, or if the user has been registered. If 
the system accepts the registration request, it stores 
the request data and the user data in the database. The 
system executes a registration request process for the 
data of the registration request, and records the data 
25 in a form that can be displayed on an unprocessed 
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registrationrequest list screen. At this time, the system 
notifies a registration/management division via e-mail, 
etc* that the registration request is made. In response 
to the user registrationrequest, the management division 
5 of user registration activates a user registration screen 
#3 from a menu screen #4 of the system, and learns that 
the registration has been made because of a transition 
made to the unprocessed registration request list screen 
#7. Then, an access right to this system is set for the 

10 user who makes the registration request. Its details 
will be described later. The management division sets 
the access right in response to the registration request, 
so that the user can use this system within the scope 
of the givenaccess right . Auser registration information 

15 change screen #5 is provided so that the management 
division changes, deletes, etc. an access right. 

The user proceeds from the initial screen #1 to 
a login screen #3, for example, with the press of a login 
button, based on the accepted registration request. When 

20 the user successfully logs in to the system on the login 
screen #3, a menu screen #4 appears . From the menu screen 
#4, a term description screen can be open in order to 
view a description of a term used for the display. 

The user can proceed to each of screens with the 

25 click of. a button to each of the screens on the menu 



screen #4 . 

search/inquiry of agreement information 
An agreement information search/inquiry function 
is provided to obtain target agreement information based 
5 on a predetermined key. Its output is made as an agreement 
list as described above, or as agreement contents or 
balance data of an agreement original (for example, a 
summary of the agreement) . As this search/inquiry, 
screens to which the display can proceed from the menu 

10 screen #4 of Fig. 7 are an agreement management number 
search screen #8 , a patent and others number search screen 
#9, a party and others search screen #11, an agreement 
relevant division search screen #12, a text data traverse 
search screen #13, and an other search screen #14. 

15 From the patent and others number search screen 

#9, the display proceeds to a number specification method 
screen #10, on which the user can view the description 
of how to input a number of a patent, etc. If the user 
does not know a particular party (company code) when 

20 he or she specifies the party, the user can proceed from 
the party and others search screen #11 to a code inquiry 
screen 1, on which he or she can examine the code of 
the party. If a company code is input as a party from 
the party and others search screen #11, agreement 

25 information in which the party is involved is searched. 
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The user can proceed also from the agreement relevant 
division search screen #12 to a code inquiry screen #2 
in order to examine a code of a relevant division. 

On the other search screen #14, the user can open 
5 a search method description screen #15, on which he or 
she can view a description of a search method. 
Additionally, the user can open a code inquiry screen 
#16, on which he or she can search for a necessary code. 
When the user searches for a necessary code, he or she 

10 opens from the code inquiry screen #16 a code inquiry 
screenn of various types used for the search, and searches 
for the target code. The user who obtains the search 
method and the code in this way inputs a search conditional 
expression from the other search screen #14. The input 

15 search conditional expression is displayed on a 
conditional expression display screen #17. 

When the search is made from a search screen to 
which a transition can be made from the menu screen #4, 
an agreement list screen #18 of Fig. 8 is displayed. 

20 On the agreement list screen, for example, every 30 
agreements are displayed, and the display can switch 
to a preceding or succeeding page. However, this screen 
can be implemented as a scroll screen on which all of 
agreements are displayed. From the agreement list screen 

25 #18, the display can proceed to an agreement data download 
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screen #23, an agreement original screen #21, or an 
electronically stored document list screen #20. Since 
some users do not require balance data for the display 
or the printing of an agreement original. A balance 
5 information addition display verification screen #19 
is provided as a screen for selecting whether agreement 
data is output with or without balance data, in this 
pref erred embodiment . If sucha selection is not required, 
there is no need to provide the verification screen #19. 

10 Additionally, on the agreement list screen #18, 

agreement list printing, agreement originals collective 
printing, and each agreement original printing can be 
made . I f downloading of an electronically stored document 
is specified from the agreement list screen #18, an 

15 electronically stored document list screen #20 is 
displayed. Then, if downloading of a particular 
electronically stored document is specified, a 
downloading destination and "others" screen #22 is 
displayed. Upon completion of the downloading, this 

20 screen #22 is closed. Additionally, if the electronically 
stored document list screen #20 is open from the agreement 
list screen #18, the display can also return to the 
agreement list screen #18. Or, if the electronically 
stored document list screen #20 is open from the agreement 

25 original screen #21 to be described later, the display 
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can return to the agreement original screen #21. From 
the agreement original screen #21, the display canproceed 
to the electronically stored document list screen #20, 
the agreement list screen #18, or the download screen 
5 #23. Furthermore, from the agreement original screen 
#21, agreement originals collective printing, or each 
agreement original printing can be made. 

If particular agreement data is specified on the 
agreement list screen #18, the display proceeds to the 

1 0 agreement data download screen #23 , on which the agreement 
data is downloaded. If the agreement data download screen 
#23 is open from the agreement list screen #18, the display 
can return to the agreement list screen #18. Or, if the 
agreement data download screen #23 is open from the 

15 agreement original screen #21, the display can return 
to the agreement original screen #21. 

With the click of an implementation report (such 
as royalty report) state inquiry button on the menu 
screen #4 of Fig. 7, the display makes a transition to 

20 an implementation report ( such as royalty report ) state 
inquiry screen #25. An agreement may sometimes include 
an obligation article to submit an implementation report 
(such as royalty report) in advance for a royalty payment 
or receipt stipulated as a consideration condition. A 

25 bill for a money amount to be paid is issued based on 
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the submission/receipt of an implementation report (such 
as royalty report) . Management division information 
(code), conditions such as a term, submission/receipt, 
etc. are specified on the implementation report (such 
5 as royalty report) state inquiry screen #25, whereby 
an implementation report (such as royalty report) state 
list of a target agreement is displayed on the screen. 
Additionally, with the click of a print button, the 
implementation report (such as royalty report) state 
10 list can be also printed. Examples of the screens will 
be described later. 

registration/modification of agreement 

information 

Registration/modification and reedition of 
15 agreement contents data, registration/modification of 
balance data, and registration/modification of an 
electronically stored document are described next as 
registration/modification of agreement information. 

For agreement information, one management number 
2 0 is assigned to one agreement, and agreement contents 
data, balance data, etc. are registered under the 
management number. Here, a consideration condition and 
balance data based on the consideration condition are 
stipulated by the unidirectional flow of agreement 
25 parties, as described earlier with reference to Figs. 
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5 and 6. Namely, a consideration condition is set in 
accordance with a license granted from a company A to 
a company B, and a consideration payment (balance data) 
from the company B to the company A is incurred under 
5 the consideration condition, so that a running royalty, 
etc. are paid to the company A (this is assumed to be 
a case 1) . However, depending on an agreement, licenses 
are mutually granted between companies A and B, 
consideration conditions are set up mutually, and 

10 consideration payments are mutually incurred (this is 
assumed to be a case 2) . 

Additionally, there is an agreement among three 
or more parties such as companies A, B, C, etc., a license 
is granted from the company A to the companies B and 

15 C, consideration conditions are respectively set for 
the companies B and C, and royalty incomes are earned 
from the companies B and C (this is assumed to be a case 
3) . 

There is also an agreement among 3 parties or more 
20 such as companies A, B, C, etc., such that a license 
is granted from the companies B and C to the company 
A, consideration conditions are set by the companies 
B andC for the company A, andpayments of running royalties, 
etc. from the company A to the companies B and C are 
25 respectively incurred (this is assumed to be a case 4) . 
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Basically/ patterns of agreement having consideration 
conditions canbe classif iedas the cases 1 to 4 . However, 
how to set a plurality of consideration conditions in 
one agreement, namely, how to manage an agreement which 
5 incurs a plurality of pieces of balance data as in the 
cases 2 to 4 becomes a problem. Especially, there arises 
a problem: which of the parties has a right, to whom 
a right is given, and how these identifications are made, 
in all of the cases 1 to 4 when viewed from the system 

10 side. The present invention can also cope with these 
cases 2 to 4 . 

One of solutions to the above described problem 
is as follows : a subnumber is added to a management number 
in the case (the cases 2 to 4 ) where a plurality of 

15 consideration conditions occur among parties in one 
agreement, and the agreement is recognized and managed 
as a plurality of agreements (these are referred to as 
virtual agreements) when viewed with the management 
number plus subnumbers, although the agreement is one 

2 0 agreement when viewed with only the management number. 

Another solution is as follows: a subnumber is not 
added, a plurality of management numbers are assigned 
in correspondence with parties for which a plurality 
of consideration conditions occur, and an agreement is 

25 managed . as one agreement having the plurality of 
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management numbers. In this case, each of the plurality 
of agreement management numbers is a virtual agreement. 
Configuration of the agreement management using 
a subnumber is first described below. 
5 From the menu screen #4 of Fig. 7 , the display can 

proceed to an agreement information registration screen 
#24 of Fig. 9. On the agreement information registration 
screen #24, registration resume/registered information 
modification, reedition, new registration (normal case 

10 (corresponding to the case 1)), and special cases (a 
plurality of registrations a (corresponding to the case 
2) , b (corresponding to the case 3) , and c (corresponding 
to the case 4) can be made. For the registration 
resume/registered information modification or the 

15 reedition, the display proceeds to a basic information 
registration screen #26 . Here, the reedition is areedited 
agreement to which an addition or a modification is made 
(an original agreement plus a memorandum of 
understanding) , when part of the agreement is later added 

20 or modified with the memorandum of understanding, etc . , 
With the reedition, a plurality of modifications are 
sometimes made to one agreement . In such a case, reedition 
is repeatedly made. 

For the normal new registration (the case 1), a 

25 number redundancy check and a subnumber occurrence check 
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are made, and the display proceeds to a basic information 
registration screen #26. 

For the special new registrations (the cases 2 to 
4) , after the number redundancy check and the subnumber 
5 occurrence check are made, a selection is made from among 
menu items for making a plurality of registrations a 
(the case 2), b (the case 3), and c (the case 4). If 
a is selected, an all parties relationship registration 
screen #24-a is open. If b is selected, an all parties 

10 relationship registration screen #24-b is open. If c 
is selected, an all parties relationship registration 
screen #24-c is open. After a parties relationship is 
registered respectively, the display proceeds to a screen 
#24-d, on which a selection window for a parties and 

15 "others" relationship (subnumber) to be input is 
displayed. When a subumber is selected, the selection 
window of a subnumber is closed, the parties relationship 
is verified on the registration screen, and the display 
proceeds to the basic information registration screen 

20 #26. 

On the all parties relationship screen #24-a (the 
case 2 ) , companies A and B can be respectively stipulated 
as a licensor and a licensee if the setting direction 
of a consideration condition is from the company A to 
25 the company B, or the relationship between the licensor 
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and the licensee becomes reverse if the setting direction 
of a consideration condition is from the company B to 
the company A, and an agreement is recognized to be two 
virtual agreements. That is, the system can identify 
5 which piece of agreement information to be registered, 
and can also display a licensor according to a management 
number plus a subnumber (for example, -1, -2 are added) . 

Additionally, on the all parties relationship 
screen #24-b (the case 3), two directions where a 

10 consideration condition is set "from the company A to 
the company B" and "from the company A to the company 
C" occur. In this case, the agreement becomes two virtual 
agreements in which the company A is a licensor. The 
system can manage these virtual agreements with a 

15 management number plus subnumbers in a similar manner 
as in the above described case. 

Furthermore, on the all parties relationship 
screen #24-c (the case 4), two directions where a 
consideration condition is set "from the company B to 

20 ' the company A" and "from the company C to the company 
A" occur. In this case, the agreement becomes two virtual 
agreements in which the company A is a licensee. The 
system can manage these virtual agreements with a 
management number plus subnumbers in a similar manner 

25 as in the above described cases. 
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The above described cases are the examples of an 
agreement concluded between two or three parties. The 
case of an agreement concluded among four parties or 
more can be coped with by generating subnumbers with 
5 a combination of the above described cases 1 to 4 . 

If any of the all parties relationship registration 
screens 24-a, b, c is selected from the agreement 
information registration screen #24, the system 
generates and adds the above described subnumber. Then, 

10 a user inputs necessary data on each registration screen 
as one agreement, whereby the agreement is registered 
to the system as agreement management data. Screens, 
which can make a transition from/to the basic information 
registration screen #26 with the click of a button linked 

15 to each screen after agreement bibliographical items, 
etc . are registered on the basic information registration 
screen #26, are a party and others information 
registration screen #29, an agreement condition 
registration screen #30, a division information 

20 registration screen #32, a licensed patent/ know-how 
information registration screen #33, a balance data 
registration menu screen #35, and a relevant information 
registration screen #36, which are shown in Fig. 10, 
in addition to a consideration condition information 

25 registration screen #27, an other agreement conditions 
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registration screen #28, and an electronically stored 
document registration screen #37 . If a patent is selected 
on the licensed patent/know-how information 
registration screen #33, the display proceeds to a 
5 licensed patent number registration screen #34, on which 
a number of the patent is registered. On the relevant 
information registration screen #36, information of an 
agent, etc., and expenses such as a consultation fee, 
a lawsuit cost, etc. can be registered. From the balance 

10 data registration menu screen #35, the display makes 
a transition to a deposit and others registration screen 
#35-1, a royalty balance registration screen #35-2, an 
arrears interest registration screen #35-3/ an other 
balance registration screen #35-4, or a bill 

15 creation/print screen #35-5, on which respective 
registration processes can be executed. From the other 
balance registration screen #35-4, the display makes 
a transition to a deposit and others registration screen 
#35-41, or a royalty registration screen #35-42, on which 

20 data as the other balance can be registered. 

Up to this point, description is provided from the 
addition of a subnumber of a virtual agreement to 
subsequent agreement information registrationprocesses 
by mainly referring to the screen transitions. The case 

25 where a subnumber is not added and one agreement is handled 
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with a plurality of management numbers is described next 
as a virtual agreement process . In this case, the screens 
#24-a, b, c, and d on which a subnumber is added become 
unnecessary as transition screens . In the above described 
5 cases 2 to 4, management numbers such as ABC1, ABC2, 
and ABC3 are grouped and managed as management numbers 
for one agreement, whereby the numbers can be registered 
respectively as virtual agreements for the registration 
of agreement data. Subsequent registration screen 

10 transitions are as described above. 

how to decide an agreement party 
The above described cases 1 to 4 are cases where 
a consideration condition accompanying right permission 
as an agreement target, and a consideration payment 

15 (deposit, royalty, etc.) of at least one party is incurred, 
when the parties of the agreement are registered. In 
the meantime, there is an agreement by which a 
consideration payment between parties is" not incurred 
even if a license is granted, and an agreement by which 

20 a license is not granted (also a consideration is not 
incurred in this case) . Furthermore, for parties 
stipulated by an agreement, there are cases such as a 
case where one of the parties becomes a licensor, and 
the other becomes a licensee, or a case where the parties 

25 become neither a licensor nor a licensee (this is referred 
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to as other parties) . For example, if attention is focused 
on a company A, there are three cases: the company A 
can possibly become a licensor, a licensee, or other 
party. When a user inputs data of a party involved in 
5 an agreement as agreement data, the system side must 
identify and record to which of a licensor, a licensee, 
and other party the input party data corresponds. 

Here, the above description is providedby assuming 
agreement parties to be a licensor and a licensee . However, 

10 for agreement parties, there are various agreement forms 
where a right is transferred, a right is not claimed 
(a right is not exercised) , etc. in addition to a form 
where a right is permitted. Parties in these forms are 
called in a variety of ways depending on an agreement, 

15 such as a licensor, a licensee, a transferor, a transferee, 
a provider, user, etc. In this preferred embodiment, 
a relationship of these rights is generically called 
or unified as a licensor and a licensee. However, the 
present invention is not limited to the licensor and 

20 the licensee, and processes of registration, etc. may 
be executed with different names depending on each 
agreement form. 

Fig. 11 shows the classification of agreement party 
relationships for enabling an agreement party 

25 relationship to be determined in the system. 
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With the system according to the preferred 
embodiment of the present invention, decision of a 
licensor and a licensee, and decision of others (parties 
are completely equal in positions, such as a cross license, 
etc,) are made with an agreement party relationship. 

In normal cases, an agreement is concluded between 
two companies, and a license is granted from one to the 
other. An agreement among many companies is separated 
into agreements between two parties, and managed by 
registering a plurality of contents of permitted rights 
in the above described data structure managed with one 
basic information . 

Agreement forms can be categorized into 9 types 
such as patterns PI to P9 of Fig. 11 . Assume that parties 
are companies A and B. In this case, their agreement 
form is categorized as any of a form where a right is 
permitted and there is a consideration condition from 
the company A, a form where a right is permitted and 
there is no consideration condition from the company 
A, a form where a right is not permitted from the company 
A, a form where a right is permitted to the company A 
and there are consideration conditions to the company 
A (namely, from the company B) , a form where a right 
is permitted and there is no consideration condition 
to the company A, and a form where a right is not permitted 
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to the company A. In the matrix shown in Fig. 11, for 
the patterns P2 to P9, the flow of a consideration is 
a unidirectional flow from one company to the other. 
Therefore, these patterns can be managed with one piece 
5 of agreement data. In the meantime, the pattern PI occurs 
in the cases 2 to 4 as described above. For example, 
the flow of a consideration from the company A to the 
company B, and the flow of a consideration from the company 
B to the company A exist as the case 2. Adopted in this 

10 case is a method for generating data which describes 
the flow of the consideration from the company A to the 
company B, and data which describes the flow of the 
consideration from the company B to 'the company A as 
agreement data even when the agreement contents of the 

15 PI are arranged with one agreement, for making the 
associationbetween thesepieces of data, and for managing 
the data. To make this association, there is a method 
for uniquely obtaining two management numbers as 
management numbers assigned to the agreement data, and 

20 for recording the association between both of the 
management numbers, for example, by recording the 
management numbers to a table in correspondence, and 
a method for adding subnumbers to one management number, 
and for registering and managing agreement information 

25 in correspondence with the subnumbers. For example, if 



54 



the management number is "01111", data which describes 
the flow of a consideration from the company A to the 
company B is managed with a number "01111-1", and data 
which describes the flow of a consideration from the 
5 company B to the company A is managed with a number 
"01111-2". In this case, the number "01111", which is 
not the subnumbers, of the respective pieces of data 
is viewed, so that both of the data are proved to indicate 
the flows of considerations accompanying the license 

10 granted by the single agreement. Besides, there is an 
advantage that the agreement can be managed with the 
data structure which describes a unidirectional flow 
of a consideration without newly providing a data 
structure for the case where bidirectional flows of 

15 considerations exist. 

It can be said that the above described management 
method is a virtual agreement method as described above, 
because a plurality of agreements are recognized to 
virtually exist for one agreement. Also the cases 3. and 

20 4 for the pattern PI are similar. 

In the cases of the patterns P5 and P9, there are 
no flows of considerations between the companies A and 
B. Therefore, the companies A and B are recognized to 
be equal inpositions, and determined to be other parties . 

25 Fig. 11 shows the patterns where the parties are 
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assumed to be the companies A and B. However, even if 
three parties or more exist, the pattern PI can be 
processed as virtual agreements as in any of the cases 
2 to 4 . Or, the patterns P2 to P9 can be processed by 
5 paying attention to the company A, and by making a 
determination . 

A registration/modification system and a search 
system of agreement information are described below based 
on configuration examples of screens. 

10 Fig. 12 exemplifies the configuration of a 

registration/modification screen . 

Main screens, via which a transition is made from 
a login screen to an agreement database registration 
screen, are exemplified. 

15 (1) of Fig. 12 shows a login screen (#3 of Fig. 

7) . This screen prompts a user to input his or her ID 
and password. On the login screen, buttons such as a 
system summary button describing the system, a user 
regis trationbutton for registering a user, a login button, 

20 and a user registration change button are provided as 
the left fields. When a user logs in to the system, a 
transition is made to a menu screen of (2) of Fig. 12 
(#4 of Fig. 7) . On the screen of (2), a system notice 
is displayed, and buttons such as agreement 

25 contents/balance data registration, statistical data, 
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search, term description, implementation report (such 
as royalty report) state inquiry, and logout are 
provided. Also on this screen, the description of the 
system can be viewed. (3) of Fig. 12 shows a screen (#24 
5 of Fig. 9) , which is displayed after a registration button 
is selected. On the screen of (3), buttons such as new 
registration, modification ( registration 

resume/registered information modification) , and 
reedition are provided. A management number field is 

10 intended to input the management number of agreement 
data to be modified or reedited when modification or 
reedition is made. If a new registration is selected 
on the screen of (3) , a transition is made to a screen 
of (4) next. On the screen of (4) (#24' of Fig. 9), a 

15 company code of a counterpart company that makes an 
agreement as a party (one company, which is a 
representative of a plurality of companies if they exist, 
can be input, or the plurality of companies can be input 
at one time) , a country name, a right permission 

20 relationship are input. The right permission 
relationship (including the presence/absence of a 
consideration) is input, so that the system determines 
any of the above described patterns PI to P9, and 
stipulates a licensor and a licensee. Here, in the cases 

25 2 to 4 for the pattern PI, with the click of any of buttons 
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a, b, and c, a transition is made to the above described 
#24-a, b, orcof Fig. 9. This example shows a bidirectional 
license from the company A (company on this side) to 
a company X (counterpart) . 
5 When these inputs are made, a transition is made 

to a screen of (5) (#26 of Fig. 9) , on which a plurality 
of windows are open . In a field of an agreement management 
system name in the top stage, the menu in the top stage 
of the above described screen of (2) is displayed, and 

10 a permission relationship is displayed in a left field 
in the second stage. For example, the relationship input 
on the screen (4) is displayed. On the screen of (5), 
the permission relationship from the company A to the 
company X is displayed. Here, the company A is normally 

15 a company on this side. If agreement parties are equal 
in positions, an arrow becomes a hyphen 

This permission relationship display field allows 
a user to learn about from whom to whom the contents 
of a right is permitted in the registration operation 

20 of agreement data, etc., which is executed by the user 
thereafter. In a right field, a management number, and 
a title indicating the type of ain agreement are displayed 
(this display is made as a result of a user registration 
operation. By default, nothing is displayed) . A lower 

25 left field indicates representatives of agreement data 
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items. Namely, basic information, an agreement target, 
other agreement conditions, consideration conditions, 
other balance, relevant information, an electronically 
storeddocument, balance data, and the like are displayed. 
5 These information items correspond to the table of 
contents. A blank in the right field becomes a basic 
information registration screen (#26 of Fig. 9) when 
a transition is made first (this portion is exemplified 
in Fig. 13) . Although contents of the agreement management 

10 system field in the top stage on the screens of (3), 
(4), and (5) of Fig. 12 are not shown, the buttons such 
as registration, search, etc. in the top stage of (2) 
are arranged, and the same contents are fundamentally 
displayed in all cases. Accordingly, even if the screen 

15 makes a transition, a user can arbitrarily make a 
transition to another process. Additionally, a user can 
reference a term description whenever he or she requires 
the description. 

Fig. 13 exemplifies the agreement basic 

20 information (bibliographical items) registration 
screen . 

On the registration screen of bibliographical 
items of basic information, an original agreement 
management number, a relevant agreement management 
25 number, a title, an agreement type, agreement parties, 
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parties involved in an agreement, an agreement conclusion 
date, an agreement effective date, an agreement term, 
and agreement termination information can be registered 
in detail. If this screen is too large to fit into the 
5 display unit, it is scrolled. 

Fig. 14 exemplifies the other agreement condition 
input screen. 

On the other agreement condition input screen, main 
provisions among agreement provisions can be registered 

10 in addition to a stipulation of treating a permitted 
right after the agreement is terminated, and the like. 
For example, if a written agreement includes a 
confidentiality provision, another window is open with 
the click of a "provision input" button of a data input 

15 part of confidentiality, and the above provision can 
be registered. In this window, main provisions such as 
a licensing provision, etc. can be registered. This 
provision registration is intended to allow a user to 
easily verify how a particular provision is stipulated 

20 when the agreement original is displayed with a 
pop-upwindow as a result of a search to be described 
below. For all of provisions of the written agreement, 
the following registration and search/inquiry of an 
electronically stored document is made. 

25 Search screens are exemplified next. Figs. 15 to 



20 show configuration examples (for search) of the 
respective screens . 

Figs. 15(a)-!, 15(a)-2, 15(a)-3, 15(a)-4, 15(a)-5, 
and 15 (a) -6 respectively exemplify screens of a 
5 management number search, a patent number search, an 
agreement party search, an agreement relevant division 
search, a text data traverse search, and other search. 
Figs . 15 ( a) -2 to 15 (a) - 6 will be described with reference 
to other figures (Figs. 16, 17 , 18, 19 and 20) . The screens 

10 15 (a) -1 to 15 (a) -6 respectively correspond to #8, #9, 
#11, #12, #13, and #14 of Fig. 7. 

On the management number search screen of Fig . 15(a) , 
a search method is specified from among an original 
agreement management number and a relevant agreement 

15 management number, a management number is input to a 
management number input field after a version number 
of agreement data is specified, and the search is started, 
so that an agreement list of Fig. 15(b) is displayed 
(#18 of Fig. 8) . Then, if one agreement is selected from 

20 the list, an agreement original indicating the contents 
of the registered agreement is displayed along with the 
management number and the title of Fig. 15(c) (#21 of 
Fig. 8) . 

Fig. 16 exemplifies the patent number search screen. 
25 With the clickof a search button after inputtinga country 
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name, a class (patent, utility model, design, trademark, 
etc.), a number type (publication, registration, etc.), 
and a patent number, etc., a search is executed, and 
an agreement list like that of Fig. 15(c) is displayed. 
5 Subsequent operations are the same. 

Fig. 17 exemplifies the agreement party search 
screen. 

With the click of a search button after inputting 
a party code ( company code) or a company name, an agreement 
10 list is displayed. 

Fig. 18 exemplifies the relevant division search 
screen . 

With the click of a search button after inputting 
a division code or name, an agreement list is output. 
15 Fig. 19 exemplifies the text data traverse search 

screen. 

This is a screen for searching for text data such 
as a registered special note, etc. in a traverse manner. 
With the click of a searchbutton after inputting a keyword, 
20 a list of agreement data including the keyword is 
displayed. A plurality of keywords can be specified. 
Fig. 20 exemplifies the other search screen. 
On the other search screen, a search can be made 
with an agreement type, a party classification, an 
25 agreement counterpart country, an agreement conclusion 
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date, an agreement expiry date, a search expression, 
etc. Asearchexpressionof Fig. 20 shows one input example 
of a search expression. 

Fig. 21 exemplifies the display of an agreement 
5 list resultant from a search. 

In the agreement list, an agreement management 
number, and bibliographical items, etc., such as 
classification of a company on this side indicating 
whether the company on this side is a licensor, a licensee, 

10 or others (equal in positions in an agreement) , an 
agreement counterpart, an agreement type, a title, an 
agreement effective date, an agreement relevant division, 
a relevant division, an agreement storage division, a 
business division, etc. are displayed. Additionally, 

15 at the side of the bibliographical items of each agreement, 
a button instructing the display of an original, and 
a button instructing the printing are provided. With 
the click of the button instructing the display of an 
original, a screen of Fig. 21(b) appears, which allows 

20 a user to select whether or not to include balance data 
in output data. When the user selects "YES" or "NO" in 
this display selection window of balance data, a 
transition is made to the former display screen (#19 
of Fig. 8) . Also with the press of the button instructing 

25 the printing, a print selection window of balance data 



appears. Then, a user selects "YES" or "NO", so that 
an original which includes/does not include balance data 
is printed. Even if a user selects an original which 
includes balance data, the system side prohibits the 
5 display or the printing of balance data depending on 
the access right of the user. Fig. 22 exemplifies the 
agreement original display. 

On the agreement original display screen, the above 
described contents of agreement data are displayed. 

10 Display/non-display of balance data is controlled 
according to an access right, and only a person who has 
an access right is allowed to view the balance data. 
CSV downloading of agreement data 
Figs . 23 and 24 explain the downloading of agreement 

15 data in a CSV format and its display. 

Fig. 23 shows the downloading type and the format 
of agreement data. Such a type of selection screen is 
displayed as #20 of Fig. 8. Actually, only a CSV file 
name and data items are displayed. An access right 

20 required is internal data for checking an access right 
within the system. For each user, depending on his or 
her access right, a limitation is imposed on agreement 
data that he or she can download. In the case of Fig. 
23, access rights such as AG1 and AG 2 are provided. A 

25 user having the access right AG1 can download only basic 
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information, an agreement target, and other agreement 
conditions when downloading agreement data . Auser having 
the access right AG 2 can download all of agreement data 
items. Agreement data is enabled to be downloaded in 
5 a CSV (Comma Separated Value) format. However, if one 
piece of agreement data has a large amount of information, 
it is enabled to be downloaded by being separated into 
4 types of CSV files. A user downloads target data by 
specifying any of the 4 types, and a downloading by 
10 specifying destination (#22 of Fig. 8) . For the 
downloading, a limitation is imposed on a file that can 
be referenced depending on an access right. 

Fig. 24 exemplifies the configuration of a CSV 
format . 

15 As shown in Fig. 24, data in a CSV format configures 

one item of data with a total of 5 rows such as 4 rows 
as title rows of an item, and one row of data contents. 
Each item is delimited with a comma in a CSV file. 
Considering the display of a CSV file with Microsoft 

20 Excel (trademark), up to 256 columns are made displayable 
in the horizontal (column) direction, and up to 65536 
rows aremade displayable in the vertical (row) direction. 
An agreement management number (main number, version 
number, subnumber: blank if there is no version number 

25 or subnumber) is always assigned to four items at the 
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beginning of each row in order to identify the contents 
of data. A data item having a character attribute is 
enclosed by double quotation marks . Such a data structure 
is used, so that the type of contents indicated by a 
5 data value can be discerned at a glance, even when the 
data is displayed with Excel. Additionally, a data item 
having a character attribute and data are processed as 
a pair. This can avoid a phenomenon that data is made 
unidentifiable by being merely wrapped around if the 

10 data is attempted to be displayed exceeding the number 
of columns, which is restricted depending on display 
software (application) such as Excel, etc. 

registration/modification of balance data 

Fig. 25 exemplifies the 

15 (registration/modification) configuration of a 
balance data screen. 

In this figure, balance data can be registered. 
For an agreement indicated by a management number, an 
input of an agreement deposit, etc., a royalty balance 

20 input, an arrears interest input, and other balance input 
can be made. In a window under the menu items, company 
names and codes of a payer side and a payee side are 
displayed. In this window, one relationship between a 
payer and a payee is selected, a process desired to be 

25 executed is selected from among the menu items, and an 
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execution button is clicked, so that a screen for 
registering balance data is open. The reason why company 
names, etc* are displayed and made selectable in the 
window under the menu items is to cope with a virtual 
5 agreement- If there are no virtual agreements, a process 
may be selected by specifying only a management number, 
and a transition may be made to the next screen with 
the click of an execution button. 

Fig. 26 exemplifies a deposit input screen. 

10 This figure shows contents of a payment such as 

a deposit, etc. at the time of an agreement by which 
a payment is made in one lump. This is the case where 
a deposit of an agreement is paid to a company on this 
side based on the assumption that a payee side is a company 

15 A, which is the company on this side, and a payer side 
is a company X, which is an agreement counterpart . Besides, 
a payment due date, a money amount of a deposit or a 
transfer expense, a past royalty, a royalty advance, 
a currency unit, an exchange rate, a tax withholding 

20 ratio, a distribution ratio among divisions that conclude 
an agreement, and the like are recorded. A button to 
record these data items, a button to create a bill, and 
a button to return to a former screen are provided at 
the bottom of the screen. 

25 Fig . 27 exemplifies an input screen of installments 
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of a deposit, etc. 

In this figure, a money amount of an installment 
at the current time is indicated in addition to the items 
shown in Fig. 26. 
5 Fig. 28 exemplifies a royalty balance input screen. 

Also here, an agreement whose royalty balance is 
to be input is identified with an agreement management 
number and a title. A payer side and a payee side are 
displayed in a similar manner as in the case of a deposit . 

10 Besides, an implementation report (such as royalty" 
report) date, a report schedule, a payment due date, 
a royalty report amount, a payment amount, a currency 
unit, an exchange rate, a tax withholding ratio, a 
distribution among divisions, etc. are recorded. 

15 Fig. 29 exemplifies the other balance input screen. 

An agreement to be input is specified with an 
agreement management number and a title. Furthermore, 
a party relationship, a payer side, and a payee side 
are displayed. Since this figure is the other balance 

20 input screen of a running royalty, items such as an 
implementation report (such as royalty report) date, 
a royalty report amount are provided. However, for the 
other balance input screen of a deposit, etc., these 
items are not provided. The other items include a payment 

25 due date, a payment date, a billed/payment amount/ a 
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ratio, a deduction amount, other arrangements, an 
additionof a consumption tax at the time of bill issuance, 
a currency unit, an exchange rate, a tax withholding 
ratio, sharing among divisions, etc. are displayed. 
5 The balance data input screens of Figs. 26 to 29 

are merely examples, and their input item names, the 
numbers- of items, etc. are not intended to limit the 
present invention. 

implementation report (such as royalty report) 
10 state inquiry 

Fig. 30 exemplifies an implementation report (such 
as royalty report) state inquiry screen (#25 of Fig. 
7) . 

This inquiry screen is intended to manage whether 
15 a user in a division which manages an agreement either 
receives or submits an implementation report (such as 
royalty report ) based on the agreement . In this figure, 
a code or a name of an agreement management division 
as a division which manages an implementation report 
20 (such as royalty report) accompanying a consideration 
payment is specified, and a report target term (from 
month-year to month-year) , and a selection of an inquiry 
document (received/submitted or not received/not 
submitted for a report, etc.) are specified, so that 
25 data of an implementation report (such as royalty report) 
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state in accordance with the agreement managed by the 
management division can be obtained. Any one or a 
plurality of selections such as "received", "submitted", 
"not received", and "not submitted" may be specified. 
5 The implementation report (such as royalty report) 
state can be output as a screen display or print. This 
screen display is exemplified in Fig. 31. 

Fig. 31 exemplifies an implementation report (such 
as royalty report) state search result screen (#25-1 

10 of Fig. 7) . 

This figure shows an implementation report (such 
as royalty report) state list. A division name as an 
agreement management division, a target term, 
information of receipt and submission sides of an inquiry 

15 document are displayed. Additionally, in the list, a 
reference number, an agreement management number, a 
company name of an agreement counterpart, balance, a 
written agreement name, a report deadline, a report date, 
a payment due date, a bill issuance date/payment date, 

20 etc. are enumerated. An arrangement of the list can be 
determined arbitrarily. For example, data items are 
arranged in order of income and expenditure in units 
of agreement management numbers, and data items 
indicating that incomes are earnedwith the same agreement 

25 management number f romaplurality of companies are listed 
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prior to a payment. Also the payment is similar. 
access right 

In the agreement management system, how to maintain 
security is an important issue. Confidentiality must 
5 be maintained depending on an agreement in many cases, 
and a restriction must be imposed even on a person within 
a company, such as a person in an agreement management 
division, a division responsible for an agreement , etc., 
to conceal the information from a person outside a company. 

10 Additionally, some agreements must not be made public 
outside a division. Accordingly, an access right 
(including reference/registration) to the system must 
be given to each user, and an access right must be set 
for each data item/document of registered agreement 

15 information (agreement contents data, balance data, 
electronically stored documents, etc.). The present 
invention overcomes this issue with the following 
configuration. Figs. 32 to 37 explain access rights. 

According to the present invention, information 

20 to be managed, and divisions that reference the 
information are classified into groups as follows, 
(a) data to be registered/ref erenced 
(1) Data of basic information of an agreement, and data 
of other agreement conditions are classified as AG1 . 

25 (2) Data of a balance amount, such as a consideration 
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condition, etc. of an agreement is classified as AG2 . 

(3) Data to be displayed as an agreement list is 

classified as AG3 . 

(b) electronically stored files 
5 (4) Documents relevant to an agreement (written 

agreement, etc.) are classified as AG4 . 

(5) Agreement negotiation documents/materials 

(minutes, letters to/from a counterpart, etc.) are 

classified as AGS. 
10 (6) Documents within a company, which accompany 

agreement negotiation, are classified as AG 6 . 

(7) Balance information (bill, implementation report 

(such as royalty report) , etc.) based on an agreement 

is classified as AG7 . 
15 (8) Others ( statistical data, etc.) are classified as 

AG8. 

(b) Divisions to which users belong are classified into 
groups . 

(1) AA division is classified as UG1. 
20 (2) AB division is classified as UG2 . 

(3) AC division is classified as UG3 . 

(4) ... (ditto hereinafter) ... 

Then, access rights to various types of information 
are respectively defined for the user groups as indicated 
25 by a table of Fig. 32. As the user groups, for example, 
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an intellectual property division, and a management 
division of a business department are respectively 
classified as the AA and the AB divisions . Fig. 32 defines 
the agreement information groups that these user groups 
5 can access. 

Fig. 33 defines data that are accessible by the 
user groups, and belong to which divisions. Divisions 
A, B, C divisions, etc. and their subordinate departments, 
which are represented as the division data in Fig. 4, 
10 respectively correspond to business groups BUGs . Namely, 
this figure defines that the respective user groups in 
the left fields can reference data of which business 
group . 

According to Figs. 32 and 33, an access right is 
15 decided by determining whether or not information (data) 
can be accessed by a person in a certain user group, 
and whether or not an access can be made to a business 
group to which the data is relevant. 

In the meantime, for example, if setting is made 
20 to disable a person who is responsible for an agreement 
in a certain user group to view data possessed by the 
business groups of Fig. 33, it is necessary to allow 
the person to make an access by regarding the agreement 
as an agreement for which the person is exceptionally 
25 responsible. Such a mechanism is shown in Fig. 34. The 
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left fields of Fig. 34 indicate a division data item 
recorded within agreement data, and a horizontal columns 
indicate the agreement information groups. For example, 
an agreement management division, an intellectual 
5 property division responsible for an agreement, a bill 
issuance/payment request acceptance division, and other 
relevant divisions are shown. Whether or not to permit 
an access right to an agreement information group is 
determined for a user whose division matches a division 

10 stored in the division data items. Namely, even if a 
user who attempts to access agreement data is restricted 
by Figs. 32 and 33, an access to data marked with 
among data in the right columns is permitted if the user 
whose division matches a division registered in the 

15 agreement data. 

Fig. 35 indicates user data possessed by the 
agreement management system for users who are permitted 
by a request to use the system. Auser ID (employee number) , 
a user group type, a user division, information of an 

2 0 additional post in a division, an electronic mail address 
to which notification of term management, etc. is made, 
a password, a valid term of the password, a registration 
right, etc. are stored. A person who is permitted to 
access this system is limited to the persons who are 

25 registered to the user data of Fig. 35. Additionally, 
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whether or not a person can access each agreement data 
item, etc. is determined with the above described 
determinations of the permission/prohibition of Figs. 
32, 33, and 34 depending on a user group type and a user 
5 division (division code) of Fig. 35 . A registration right 
indicates whether or not a user has a right to be able 
to register agreement data, etc. to the system. This 
is information that a management division determines 
at the time of the above described user registration 
10 request, and registers to this system. The additional 
post field allows an access right resultant from a logical 
OR of access rights of two divisions or more to which 
a plurality of j obs belong if one person does the plurality 
of jobs. 

15 Fig. 36 is a flowchart showing the flow up to user 

registration. 

Arequestor first opens auser registration request 
screen, and inputs an employee number, password, and 
e-mail information (step SI) . With the press of a request 

20 button, e-mail is transmitted to a registration 
management division. The registration management 
division receives the e-mail, and verifies that the 
requestor exists (step S2) . Next, the registration 
management division verifies the requestor on the 

25 unprocessed registration request list screen (step S3) . 
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Then, the registration management division sets a 
verification result, and the giving of a right to use 
the system (step S4) . As is executed by the registration 
management division in this way, the user registration 
5 process is a verification process of a requestor who 
requires a special user ID and password. When the right 
to use the system is given to the requestor in step S4, 
request result e-mail is transmitted to the requestor. 
The requestor that receives the request result e-mail 

10 proceeds to a login screen, on which the requestor inputs 
the user ID and password to log in to the system.. 

Fig. 37 is a flowchart showing the flow from login 
to the giving of an access right. 

Fig. 37(a) is first described. 

15 When a user logs in to the system with a password, 

etc. instepSlO, the system verifies the presence/absence 
of an employee number, and an employee division with 
the newest employee master in step Sll. In step S12, 
' if the employee number is determined not to exist, the 

20 access is denied. If the employee number is determined 
to exist, the system verifies, with the user master (Fig. 
35) , the presence/absence of the employee number , whether 
or not the user' s division matches the employee master, 
the password, and the valid term of the password in step 

25 S13. If the employee number is determined not to exist 
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in step S14, the access is denied. If the employee number 
is determined to exist, the system determines whether 
or not the employee division matches in step S15. If 
the employee division does not match, the access is denied. 
5 If the employee division matches, the system further 
determines whether or not the password matches. If the 
password does not match, the access is denied. If the 
password matches, the system determines whether or not 
the valid term of the password has expired. If the valid 

10 term of the password has expired, the display proceeds 
to the password change screen in step S18, on which the 
password is changed in step S19, and proceeds to step 
S20. Also if the valid term of the password does not 
expire, the flow proceeds to step S20. In step S20, the 

15 menu screen is displayed, and the display proceeds from 
the menu screen to each process screen (step S21). 

Fig. 37(b) shows a process for 

registering/referencing agreement data. Here, assume 
that a user has .an access right to make 

20 registration/reference. When a transition is made from 
the menu screen to a registration/reference process 
screen (step S25) , the scope of a given access right 
based on Figs. 32 and 33 is decided according to the 
access right giving information defined in the user master 

25 in step S26. In step S27, the access right is finally 
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decided based on the scope decided in step S26, and its 
logical OR with the access right given based on Fig, 
34. Then, in step S28, whether or not to permit an access 
is determined. If the access is rejected in S28, the 
5 user cannot make the access. If the access is permitted 
instepS28, the f lowproceeds to aprocess such as display, 
printing, etc. of agreement data. 
statistical data 

Figs. 38 to 42 exemplify screens relevant to 

10 statistical data. 

Fig. 38 shows the state of a screen transition of 
a statistical output. 

When a user first attempts to make an access to 
statistical data, whether or not to permit the access 

15 is verified based on an access right of the user. If 
the access is not permitted, the access is denied. If 
the access is permitted, the display proceeds to the 
condition specification screen. The user specifies his 
or her desired statistical data, and clicks a button 

20 to execute a statistical process on the condition 
specification screen. If the statistical data includes 
data for which the user does not have an access right, 
the data is not displayed due to the absence of the access 
right also at this time. If the access right of the user 

25 covers the entire statistical data, it is output in 
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accordance with the specified process. The display can 
include a plurality of pieces of statistical data. The 
user can print or download the data. Additionally, a 
selection to make statistical data include a balance 
5 total or detailed data, etc. is enabled depending on 
the type of statistical data as a selection at the time 
of data downloading. 

Fig. 39 exemplifies the condition specification 
screen . 

10 As output targets, aggregate data of an entire 

company, aggregate data of each headquarters, aggregate 
data of each division, and aggregate data of each 
agreement are provided. A division code or name is used 
to specify the aggregate data of each division. An 

15 agreement management number is specified when the 
aggregate data of each agreement is obtained. 
Additionally, year specification, an output form, a 
distinction between a deposit and a running royalty, 
or the like can be specified. These items are specified, 

20 and an execution button is clicked, so that specified 
statistical data is displayed. 

Figs. 40 to 42 exemplify statistical output data 
formats. 

In a balance total of an entire company shown in 
25 Fig. 40A, a total of deposit income amounts, a total 
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of running royalty income amounts, a total of deposit 
payment amounts, and a total of running royalty payment 
amounts are represented for each quarter of each year 
for the entire company. 

Fig. 40B shows the data of each headquarters, and 
a plurality of headquarters are enumerated. With the 
click of one of the headquarters, a . license balance of 
the specified headquarters is represented for each 
quarter of each year. Fig. 40C shows the data of each 
division, and a plurality of divisions are enumerated. 
In this case, the balance total of the headquarters, 
and the balance total of licenses of each division are 
displayed in a similar manner. 

Fig. 41 exemplifies a display format in the case 
where a term of the aggregate data of each agreement 
is specified. 

In this format, expenditure data is represented 
in the same arrangement under income data. Additionally, 
if a distinction between home and abroad is not made, 
the data is collectively displayed as one table. For 
only home or abroad, the data of only home or abroad 
is output. If the data is . output without making a 
distinction between a deposit and a running royalty, 
the data is collected in one table, in which a combined 
amount is displayed. 
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Fig. 42 exemplifies a display format in the case 
where a term is not specified in aggregate data of each 
agreement . 

In this case, the data is displayed in an order 
5 of specified agreement management numbers when the 
agreement management numbers are specified. In the case 
of a division code search, the data is displayed in an 
order of agreement management numbers. Since a term is 
not specified in this case, all of the effective 
10 agreements are displayed. 

Control of operations of the agreement management 
system according to the present invention is described 
below with reference to flowcharts. 

Fig. 43 is a flowchart showing a 
15 registration/modif ication/reedition process starting 
from login. The reedition is used as the following 
meaning. 

reedition/version number 

If contents of an agreement are changed with a 
20 memorandum of understanding for one agreement, contents 
obtained by incorporating an article changed with the 
memorandum in the contents of the agreement, which is 
the base, is defined to be a reedition. 

To register data of a memorandum of understanding, 
25 reedition is specified on the initial screen, the 



management number of the agreement, which is the base, 
is input, and contents of a change are input to a correction 
memorandum field, for example, by being itemized. 

At the time of reedition, the version number of 
5 the agreement management number is automatically updated 
by the system. 

Assume that memoranda of understanding are 
exchanged twice, and their contents are added. In this 
case, the version number of the agreement management 

10 number, which is originally the agreement "0000-01" (the 
first edition) , is updated to an agreement "0000-02" 
(the second edition) when the first memorandum of 
understanding is added, and further updated to an 
agreement "0000-03" (the third edition) when the second 

15 memorandum of understanding is added. 

Firstly, in step S31, the process branches to a 
route for which new registration, modification, or 
reedition of agreement information is selected. In the 
case of new registration, the process proceeds to step 

20 S32, in which an agreement management number is decided. 
Then, in step S33, an agreement counterpart and a country 
are decided. In step S34, an agreement form is decided. 
An agreement form is decided with the patterns PI to 
P9 of Fig. 11. In the case of modification, an agreement 

25 management number is decided in step S35. In the case 
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of reedition, an agreement management number is decided 
in step 36 . Then, in step S37 , a version number is updated. 
In step S38, data other than balance data is copied and 
extended in a database. 
5 Fig. 44 is a flowchart showing a subnumber process . 

In the following cases, the system adds a subnumber 
as a virtually separate agreement, and manages the 
agreements. 

(1) Case where a consideration income and a 
10 consideration payment are mutually made between the same 

parties in one agreement. 

(2) Case where a party (licensor) of this system grants 
a plurality of agreement parties (licensees) a license 
in one agreement. 

15 (3) Case where a license is granted from a plurality 
of agreement parties (licensors) to a party (licensee) 
of this system in one agreement, and a consideration 
payment is incurred for each of the plurality of parties . 

Fig. 44(a) shows a subnumber process at the time 

20 of registration. In step S41, parties are specified, 
and a subnumber 01 is added if the parties are initially 
registered. In step S42, the parties are exchanged, and 
a subnumber is updated when a transition is made to a 
screen on which the next agreement information is 

25 registered. In step S43, the bibliographical items of 
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the agreement information other than the party data of 
the basic information are copied to generate data. 

Fig. 44(b) shows a subnumber process in the case 
of modification and reedition. Especially, in the case 
5' of reedition, also data to which a subnumber is added 
is copied in step S38 of Fig . 43 . As the subnumber process 
at the time of modification or reedition, only a process 
for deciding a subnumber of a modification target is 
executed as indicated by step S44. If the system is not 

10 built as a system which supports a subnumber, the control 
shown in Fig. 44 is unnecessary. 

Fig. 45 is a flowchart showing a process for 
registering basic information. 

In step S51, the system decides bibliographical 

15 items among basic information. The bibliographical items 
include an agreement title, an agreement type, agreement 
parties, an agreement conclusion date, an agreement term, 
an agreement expiry date, an agreement termination date, 
etc. In step S52, data of relevant divisions within a 

20 company is decided. Examples of the relevant divisions 
include an agreement management division, an agreement 
conclusion division, a division relevant to a balance, 
other relevant divisions, etc. The flow of Fig. 45 is 
the process activated when "bibliographical items" or 

25 "relevant division within a company" of the basic 
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information is clicked on the screen of (5) of Fig. 12. 
This process is intended to register bibliographical 
items and relevant divisions respectively. Accordingly, 
with the click of the "bibliographical items", which 
5 are the contents of the basic information, the 
bibliographical items are input, and then the process 
moves to an input of the relevant divisions within the 
company. Additionally, with the click of "relevant 
divisions within a company" of the basic information, 

10 a screen for registering relevant divisions within a 
company is displayed. When the registration of the 
relevant divisions within the company is terminated, 
the display returns to (5) of Fig. 12. I f a bibliographical 
item is desired to be registered after the relevant 

15 divisions within the company are registered, the 
"bibliographical items" is clicked after the display 
returns to (5) of Fig. 12, and the bibliographical item 
is input. 

Fig. 46 is a flowchart showing a process for 
20 registering data of an agreement target. 

At the time of the data registration of an agreement 
target, an input right, license, etc. is decided for 
each form of permitted right classification (normal 
license, exclusive license (or exclusive right), etc.). 
25 In step S53, contents of each input of a licensed 
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patent/know-how/product are decided (patent number 
specification is repeatedly made by the number of patent 
numbers to be specified) . In step S54, a subsidiary, 
etc. are decided as a permittee/permitter . 
5 Fig. 47 is a flowchart showing a process for setting 

other agreement conditions. 

In step S61, how to treat an agreement after 
termination of the agreement is decided, and the process 
is completed. 

10 Fig. 48 is a flowchart showing a process for setting 

consideration conditions . 

In step S64, balance classification/a deposit, 

etc. /running royalty/ an arrears interest are decided. 

In step S65, predetermined items such as a payment due 
15 date, a payment month, and the presence/absence of an 

implementation report (such as royalty report) , etc. 

are decided. Then, in step S66, counterpart information 

is decided. This information is used to transmit a bill, 

etc. In step S67, data of distribution/sharing within 
20 a company is decided, and the process is completed. 

Fig. 49 is a flowchart showing a process for 

inputting relevant information. 

Relevant information can be input with the click 

of an "agent" button in (5) of Fig. 12. When an input 
25 format is displayed, information of ah agent involved 
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in an agreement, expenses, etc. are decided. This process 
is similar also when written agreement data is modified. 
At the time of modification, registered data is displayed, 
contents are decided after being modified with 
5 overwriting, and the data is reflected on the system. 

Fig. 50 is a flowchart showing a process for 
registering an electronically stored document. 

In the electronically stored document 
registration process, a document is decided as an 
10 electronically stored document in step S73 . In step S74, 
the electronically stored document is registered to a 
predetermined folder (registered to a database on the 
server side) in step S74, and the registration is 
completed. 

15 Fig. 51 is a flowchart showing a process for 

registering balance data. 

Firstly, in step S81, an input screen of balance 
information based on consideration conditions is 
displayed. Step S82 is applied to the case where agreement 

20 data is managed with a subnumber. Namely, data with a 
subnumber, which is added to a management number, is 
displayed. Additionally, data of a selected subnumber 
is decided. In step S83, data of a deposit, etc., 
installments, a running royalty, an arrears interest, 

25 etc. are decided. Especially, a correspondence between 
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an income and a payment of a running royalty, a payment 
due date, a payment amount, a currency unit, etc. are 
decided. Then, instepS84, data of distribution/sharing 
within a company is decided, and the registration is 
5 completed. Contents of the registered balance data are 
reflected on data including balance data of an agreement 
original, and on data downloaded as CSV data. 

Fig. 52 is a flowchart showing a process for 
registering other balance information . The other balance 
10 information includes the following. 

- other balance (installments) 

If distribution/sharing within a company is made for 
installments as a consideration of an agreement, its 
balance data is input. 
15 - other balance (running royalty) 

If distribution/sharing within a company of a running 
royalty incurred is made, its balance data is input. 

- other balance (lump sum) 

If distribution/sharing within a company of a deposit 
20 incurred when or after an agreement is concluded is made 
as a consideration in an agreement, its balance data 
is input. 

Additionally, for example, if a transfer expense 
is received in accompaniment with a transfer agreement, 
25 or if money is received as a transfer penalty charge 
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for an agreement which does not incur a consideration 
(such as a no-consideration license agreement, 
no-consideration cross agreement, etc.) , 

distribution/sharing within a company is input if it 
5 is made . 

Description is provided with reference to Fig. 52 . 
In step S85, if an agreement is managed with subnumbers, 
data of the subnumbers added to a management number is 
displayed, and data of a selected subnumber is decided. 

10 In step S86, distribution/sharing of a deposit, 
installments, a running royalty, etc. is decided. In 
step S87, the distribution/sharing within a company is 
decided, and the registration is completed. 

Fig. 53 is a flowchart showing a search/inquiry 

15 process. 

Firstly, in step S91, specification of each 
search/inquiry is decided. For each search/inquiry, a 
management number, a number of a patent, etc., a party, 
a relevant division, text data, etc. are specified. In 

20 step S92, the system makes a data search with a search 
condition. In step S93, a search result is decided. In 
step S94, the search result is output as an agreement 
list . This output is made by being displayedon the display 
unit, or by being printed on a paper medium. Then, as 

25 described with reference to Fig. 8, the process is 
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completed with a user instruction, the process is 
completed after making an output (display/print) by 
specif ying an agreement original (stepS95), the process 
is completed after downloading and outputting a document 
5 with electronically stored document specification (step 

596) , or the process is completed after outputting data 
in a CSV format with downloading specification (step 

597) . In step S94, all pieces of data having the same 
management number to which subnumbers are respectively 

1 0 added are output i f the data is managed with the subnumbers . 
This is similar also for an agreement original output. 

Fig. 54 is a flowchart showing an alarm process. 
Firstly, the system cyclically scans a 
corresponding item based on registered agreement data 

15 and balance data. Then, in step S101, a process for an 
agreement termination, implementation report (such as 
royalty report) receipt, implementation report (such 
as royalty report) submission, or installments is 
executed. The implementation report (such as royalty 

20 report) receipt process, the implementation report (such 
as royalty report) submission process, and the 
installments process respectively succeed to the 
flowcharts shown in Figs. 55, 56, and 57. In the case 
of the agreement termination, an agreement termination 

25 schedule is automatically notified in step S102 . In step 
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S103, data of an agreement expiry date is obtained. In 
step S104, a comparison is made between the current date 
and time and the agreement expiry date. In step S105, 
it is determined whether or not the agreement expiry 
5 date is ahead of the current date by a predetermined 
number of days (or a predetermined number of months) . 
In step S106, an e-mail notifying that the agreement 
termination is close is transmitted to a responsible 
person registered to an agreement management division. 
10 In step S107, e-mail notifying that the agreement 
termination is close is transmitted to a responsible 
person registered to a division responsible for the 
agreement . 

Fig. 55 is a flowchart showing an alarm process 
15 for the receipt of an implementation report (such as 
royalty report) . 

In step Sill, implementation report (such as 
royalty report) data to be received is extracted from 
agreement data. In step S112, the system checks an 
20 implementation report (such as royalty report) month 
(deadline) . In step S113, the system checks the current 
date and time, and the presence/absence of an 
implementation report (such as royalty report) . Then, 
in step S114, the system checks whether or not a 
25 predetermined deadline of data whose implementation 
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report (such as royalty report) has not been received 
yet has passed. In step S115, the system transmits e-mail 
to a responsible person in a management division. 

Fig. 56 is a flowchart showing an alarm process 
5 for the submission of an implementation report (such 
as royalty report) . 

In step S121, implementation report (such as 
royalty report) data to be submitted is extracted from 
agreement data. In step S122, the system checks an 

10 implementation report (such as royalty report) month 
(deadline) . In step S123, the system checks a date and 
time^ which is ahead of the current day by a predetermined 
number of days. In step S124, the system extracts an 
agreement whose deadline is ahead of the current day 

15 by the predetermined number of days . In step S125, e-mail 
for calling attention to the extracted agreement is 
transmitted to a responsible person in a management 
division . 

Fig. 57 is a flowchart showing an alarm process 
20 for installments. This figure assumes the case where 
a company on this side receives installments money. 

In stepS 131, an agreement to be paid in installments 
is extracted from agreement data . InstepS132, a payment 
due date is checked for data yet to be paid in installments . 
25 In step S133, a date and time, which is ahead of the 
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current date and time by a predetermined number of days, 
is checked. In step S134, an agreement whose due date 
is ahead of the current day by the predetermined number 
of days is extracted. In step S135, e-mail for calling 
5 attention is transmitted to a responsible person in a 
management division. E-mail for notifying that a payment 
due date is close is transmitted to a management division 
on a date and time, which is ahead of a payment due date 
by a predetermined number of days also when the company 

10 on this side pays an installment. 

Fig. 58 is a flowchart showing a process for 
statistical data. 

Firstly, in step S141, a statistical calculation 
target is decided. In step S142, a calculation term is 

15 decided. A term is not specified in some cases . Thereafter, 
the process branches according to a user instruction. 
If the user instructs the total balance of an entire 
company, data of a royalty balance, etc. in the database 
is added and aggregated for each term in step S143. The 

20 aggregated data is output (displayed/printed) in a 
predetermined format in step S148. If the user instructs 
the balance total of each business headquarters, data 
of a royalty balance, etc. in the database is added and 
aggregated for each term in step S144. Then, the 

25 aggregated data is output in step S148. If the user 
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instructs the balance total of each division subordinate 
to a business headquarters, data of a royalty balance, 
etc. in the database is added and aggregated in step 

5145. Then, the aggregated data is output in step S148. 
If the user instructs the balance total of each agreement 
for each term, data of a royalty balance, etc. in the 
database are added and aggregated for each term in step 

5146. Then, the aggregated data is output in step S148. 
If the user instructs the total balance of each agreement 
up to the current time, data of a royalty balance, etc. 
in the database is added and aggregated in step S147. 
Then, the aggregated data is output in step S148. 

According to the present invention, various 
agreements or information (documents) of agreements, 
etc., which spread over divisions, can be managed in 
common without lowering the level of security, and 
agreement data and balance data can be provided to a 
user on demand. 



